Part of #39211

Fixes a few small issues with the JSDoc types in @wordpress/core-data.

 - `undefined` was the wrong return type for the given files. removing that type to remove the error and leaving them untyped.
 - acknowledge that the `undoIgnore` parameter is optional for `editEntityRecord`
 - return type of `__experimentalBatch` is a function that returns a `Promise`, not a `Promise`

Co-authored-by: Adam Zielinski <[email protected]>

Part of #39211

Fixes a few small issues with the JSDoc types in @wordpress/core-data.

 - queue of actions in `batch` was untyped, added type holding vague structure of type
 - `await`'ed `Promise` called `resolve()` but wasn't typed as `Promise<void>`. this may not be possible in JSDoc whereas it is in `.ts` with the type parameter. I've made it `resolve(undefined)` to get around this.
 - inner loop of batched actions had ambiguous types (list of things or tuple?) and I've extracted the inline assignments to variables in order to eliminate the ambiguity
 - `ObservedSet` used spread arguments for `Set`'s 1-arity functions. I've replaced `...args` with `value` to match the API of `Set`

Part of #39211

Previously it was possible that we fail to register a batch size from
the server and we leave the batch size null.

In this patch we fallback to the Core-defined default of 25.

Part of #39211

Fixes minor type-related issues that are mostly problems with JSDoc
type signatures. In a couple of places a safe-defaulting fallback
has been added where the existing JS code assumes the presence of
nullable data.

Part of #39211

Previously we have been calling `createContext()` without any
arguments, but there's a funny note in the official React type
for that function.

> // If you thought this should be optional, see
> // DefinitelyTyped/DefinitelyTyped#24509 (comment)

Although not passing an argument is practically the same as passing
`undefined` as the argument we have a type error that TypeScript
doesn't like while we're relying on it to parse JS files with the
JSDoc typings.

In this patch we're just adding the explicit `undefined` which should
have no behavioral change on the output but removes the type issue.

Part of #39211

Fixes minor type-related issues that are mostly problems with JSDoc
type signatures. In a couple of places a safe-defaulting fallback
has been added where the existing JS code assumes the presence of
nullable data.

…#39526)

Part of #39211

Previously we have been calling `createContext()` without any
arguments, but there's a funny note in the official React type
for that function.

> // If you thought this should be optional, see
> // DefinitelyTyped/DefinitelyTyped#24509 (comment)

Although not passing an argument is practically the same as passing
`undefined` as the argument we have a type error that TypeScript
doesn't like while we're relying on it to parse JS files with the
JSDoc typings.

In this patch we're just adding the explicit `undefined` which should
have no behavioral change on the output but removes the type issue.

Part of #39211

Previously it was possible that we fail to register a batch size from
the server and we leave the batch size null.

In this patch we fallback to the Core-defined default of 25.

Part of #39211

The `Function` type in `onSubKey` caused an issue when enabling TypeScript
for the `core-data` module (when analyzing JS files) because it's not a
callable interface.

In this patch we're creating a transition type `AnyFunction` and using that
as the type in `onSubKey` to remove the type error.

After enabling TypeScript for the module we'll be able to provide better
types on the function directly, but for now this prevents raising an error.

We want to do great things with the `core-data` type system but all of these
little nuisances get in the way when we're trying to study those things in
isolation. This is a preparatory change to eliminate some of the noise in the
existing types.

As a type-only change this will have no impact on the built code.
Please audit the types and the introduction of the `types.ts` where
we import an actual TypeScript type into JSDoc through `@typedef`.

Note that this change doesn't "fully-type" `onSubKey` in the sense
that it provides full inference for the passed-through reducer.
The goal is merely to avoid creating type errors when activating
TypeScript across the module.

Part of #39211

In this patch we're expanding the type signature of `useQuerySelect`
and fixing a minor type-related issue that was formerly there.

We want to do great things with the `core-data` type system but all of these
little nuisances get in the way when we're trying to study those things in
isolation. This is a preparatory change to eliminate some of the noise in the
existing types.

As a type-only change this will have no impact on the built code.
Please audit the types and the use of the wrapper `EnrichedSelectors`.

Part of #39211

In this patch we're adding some types to the undo state tracked
in the core data store. Additionally we're intializing it in one
atomic operation whereas previously that took two partial assignments.

Futher, a JSDoc comment has been moved from its previously erroneous
location and back to the function it describes. This error had been
overlooked in a previous change to the module.

The purpose is to remove type issues when toggling on TypeScript
across the `core-data` package.

This is almost entirely a type-level change but the initialization
of `UNDO_INITIAL_STATE` has been collapsed into a single assignment.

Verify that the editor undo/redo functionality works as expected.
Given that the one code change impacts the initialization it should
be quickly obvious if there's a problem or regression with undo/redo.

Part of WordPress#39211

Fixes minor type-related issues that are mostly problems with JSDoc
type signatures. In a couple of places a safe-defaulting fallback
has been added where the existing JS code assumes the presence of
nullable data.

…WordPress#39526)

Part of WordPress#39211

Previously we have been calling `createContext()` without any
arguments, but there's a funny note in the official React type
for that function.

> // If you thought this should be optional, see
> // DefinitelyTyped/DefinitelyTyped#24509 (comment)

Although not passing an argument is practically the same as passing
`undefined` as the argument we have a type error that TypeScript
doesn't like while we're relying on it to parse JS files with the
JSDoc typings.

In this patch we're just adding the explicit `undefined` which should
have no behavioral change on the output but removes the type issue.

Part of #39211

In this patch we're adding some types to the undo state tracked
in the core data store. Additionally we're intializing it in one
atomic operation whereas previously that took two partial assignments.

Futher, a JSDoc comment has been moved from its previously erroneous
location and back to the function it describes. This error had been
overlooked in a previous change to the module.

The purpose is to remove type issues when toggling on TypeScript
across the `core-data` package.

This is almost entirely a type-level change but the initialization
of `UNDO_INITIAL_STATE` has been collapsed into a single assignment.

Verify that the editor undo/redo functionality works as expected.
Given that the one code change impacts the initialization it should
be quickly obvious if there's a problem or regression with undo/redo.

Part of #39211

In this patch we're adding some types to the undo state tracked
in the core data store. Additionally we're intializing it in one
atomic operation whereas previously that took two partial assignments.

Futher, a JSDoc comment has been moved from its previously erroneous
location and back to the function it describes. This error had been
overlooked in a previous change to the module.

The purpose is to remove type issues when toggling on TypeScript
across the `core-data` package.

This is almost entirely a type-level change but the initialization
of `UNDO_INITIAL_STATE` has been collapsed into a single assignment.

Verify that the editor undo/redo functionality works as expected.
Given that the one code change impacts the initialization it should
be quickly obvious if there's a problem or regression with undo/redo.

Part of #39211

The `Function` type in `onSubKey` caused an issue when enabling TypeScript
for the `core-data` module (when analyzing JS files) because it's not a
callable interface.

In this patch we're creating a transition type `AnyFunction` and using that
as the type in `onSubKey` to remove the type error.

After enabling TypeScript for the module we'll be able to provide better
types on the function directly, but for now this prevents raising an error.

We want to do great things with the `core-data` type system but all of these
little nuisances get in the way when we're trying to study those things in
isolation. This is a preparatory change to eliminate some of the noise in the
existing types.

As a type-only change this will have no impact on the built code.
Please audit the types and the introduction of the `types.ts` where
we import an actual TypeScript type into JSDoc through `@typedef`.

Note that this change doesn't "fully-type" `onSubKey` in the sense
that it provides full inference for the passed-through reducer.
The goal is merely to avoid creating type errors when activating
TypeScript across the module.

Part of #39211

In this patch we're expanding the type signature of `useQuerySelect`
and fixing a minor type-related issue that was formerly there.

We want to do great things with the `core-data` type system but all of these
little nuisances get in the way when we're trying to study those things in
isolation. This is a preparatory change to eliminate some of the noise in the
existing types.

As a type-only change this will have no impact on the built code.
Please audit the types and the use of the wrapper `EnrichedSelectors`.